App Runner の vCPU数変更に伴う性能影響とCloudWatchメトリクスを確認してみた
2023年4月の AWS App Runne の アップデートで、実行環境となるコンテナインスタンスのvCPU数の選択が増え、従来の「1」,「2」に加え、 「0.25」、「0.5」、「4」 のvCPU数を指定した利用が可能になりました。
今回、vCPU数を抑制した場合の影響を把握するため、一定時間ループでCPU負荷を発生させるダミーアプリを用意。 vCPU数を変化させる事による性能への影響と、App Runner の CloudWatchメトリクス 「CPUUtilization」 として記録される値について、確認する機会がありましたので紹介させて頂きます。
検証環境
App Runner
App Runner Workshop で紹介されている Deploying to AWS App Runner with Docker を踏襲。サンプルコードに5秒間のループ処理を追加する事で、CPU負荷を発生させました。
const express = require('express');
const app = express();
const port = 3000;
app.get('/', (req, res) => {
let i = 0;
for (let t = new Date().getTime(); new Date().getTime() - t < 5000;) {
i++;
}
console.log('Loog count: ' + String(i));
res.send('Hello World!');
});
app.listen(port, () => {
console.log(`Example app listening at http://localhost:${port}`);
});
App Runner の ヘルスチェックは TCPで実施する設定とし、負荷影響を排除しました。
1台のインスタンス性能を測定するため、Auto Scalingの最小、最大サイズはともに「1」を指定しました。
クライアント
App Runner のデプロイ後、 同一リージョンの CloudShell から1並列で curl を利用した実行を試みました。
URL="https://xxxxxxx.ap-northeast-1.awsapprunner.com"
while true
do
curl ${URL}
done
結果
- vCPU数毎の結果一覧
| vCPU数 | CPUUtilization | ループ回数(/s) |
|---|---|---|
| 0.25 | 256 | 16559 |
| 0.5 | 506 | 24328 |
| 1 | 1009 | 53477 |
| 2 | 1853 | 74865 |
| 4 | 1973 | 75537 |
- vCPU毎のグラフ(インスタンス別)
※ 今回、サーバ (Node.js) はシングルプロセス、クライアントの並列数も1であった事で、vCPU:4のCPUリソースは全て活用できていなかったと推測されます。
まとめ
vCPU:1のインスタンス と vCPU:0.25、0.5のインスタンス の計測値から、vCPU数に応じた CPUリソースの割当制限が行われている事が確認できました。
また、App Runner の CloudWatch メトリクス 「CPUUtilization」については、1秒あたりのCPU実行時間 (CPU execution time）が ミリ秒の単位で記録されている可能性が高い様に見受けられました。
従来から稼働中のApp Runner、 過去の CPUUtilization、MemoryUtilization の記録を確認し、 ピーク時(最大値) の CPUUtilization が 500、MemoryUtilization が 1GB を 大きく下回っている場合、スペックダウンによるコスト抑制が 低リスクで実現できる可能性があります。
逆に応答速度が求められるワークロードで、 1vCPUあたりの CPUUtilization の値が 1000に近い値となっている場合には、 CPU性能不足による遅延回避のため、スケールアウトを促す設定 (オートスケール設定の同時実行数の抑制)とあわせて、マルチコアやメモリを活用できるワークロードであれば、インスタンスのスペックアップもお試しください。
追記(2023年8月31日)
2023年8月のアップデートで、CPU Utilization の記録値は 100を上限とする使用率(パーセント)で確認可能となりました。
